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Abstract: 

As  the  Services  move  to  transform  joint  and  coalition  operations,  a  new  capability  being 
contemplated  for  the  transformed  forces  is  synchronizing  manned-combat-vehicle  and 
unmanned-combat-vehicle  target  engagements.  However,  we  are  just  beginning  to  work 
out  the  details  for  implementing  such  a  symphony  of  coordinated  human  and  machine 
decisions  and  actions.  One  challenge  in  realizing  an  implementation  is  the  selection  of 
command  and  control  architectural  components  and  their  relationships  that  will  provide 
the  precision  and  flexibility  needed  for  joint  and  coalition  warfare.  We  describe  an 
experiment  in  building  an  environment  for  comparing  command  and  control 
architectures.  The  experiment  involves  extending  the  One  Semi-Automated  Forces 
(OneSAF)  simulation  environment  to  support  analysis  of  alternative  architectures  for 
integration  of  control  of  autonomous  combat  vehicles  with  control  of  manned  combat 
vehicles.  The  autonomous  combat  vehicle  being  simulated  is  the  Loitering  Attack 
Missile  (LAM)  which  is  being  considered  as  a  supporting  indirect  fire  weapon  for  the 
Future  Combat  System  (FCS). 

Background 

As  with  current  operations,  future  Joint  Operations  will  require  availability  a  range  of 
direct- fire  and  indirect-fire  (non-line-of-sight)  weapons  to  engage  enemy  targets.  One 
such  weapon  system  being  considered  is  the  non-line-of-sight  Launch  System  (NLOS- 
LS)  with  associated  indirect-fire  missiles:  the  Precision  Attack  Missile  (PAM)  and 
Loitering  Attack  Missile  (LAM)  [1],  The  NLOS-LS  set  of  systems  is  expected  to  be  a 
key  component  of  a  suite  of  indirect  fire  weapons  available  to  future  commanders  [2], 


An  active  area  of  review,  analysis  and  research  has  been  in  the  consideration  of  the 
impact  of  the  ongoing  revolution  in  information  systems  to  command  and  control  systems 
[3,  4,  5,  6],  The  notion  that  “information  age”  warfare  is  in  some  sense  “network  centric” 
implies  a  capability  to  share  information  across  networks  to  dynamically  “understand” 
the  state  of  the  battlespace  better  than  your  opponents  (information  dominance)  and 
dynamically  alter  plans  based  on  that  understanding  (i.e.  “get  inside  the  decision  cycle” 
of  opposing  force  commanders). 

Fundamental  to  these  considerations  for  future  command  and  control  systems  is  the  issue 
of  system  architecture  comparison  and  selection.  This  paper  will  provide  an  overview  of 
an  architecture  comparison  environment  being  implemented  for  an  undergraduate  project 
in  control  system  architecture  comparison.  There  have  been  many  efforts  in  software 
architecture  comparison  over  the  past  ten  years  [7,  8,  9].  The  cadet  work  will  focus  on 
design  and  implementation  of  airspace  deconfliction  algorithms.  For  that  area,  they  will 
compare  three  different  missile  control  architectures:  centralized  control, 
semiautonomous  control,  and  autonomous  control.  They  will  also  "brainstorm" 
Information  Assurance  (IA)  issues.  In  order  for  the  cadet  deconfliction  work  to  be  done, 
the  missiles,  targets,  and  obstacles  have  to  be  identified  and  the  simulation  dynamics 
provided. 

*  This  work  was  partially  supported  by  an  endowment  establishing 
the  Adam  Chair  in  Information  Technology.  The  views  expressed 
herein  are  those  of  the  authors  and  do  not  purport  to  reflect  the 
position  of  the  United  States  Military  Academy,  the  Department  of 
the  Army,  or  the  Department  of  Defense. 
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Currently,  we  have  the  of  the  OneSAF  Testbed  Baseline  (OTB)  simulation  environment 
as  modified  by  the  U.  S.  Army  Communications  Enectronics  Command  (CECOM)  under 
a  Defense  Advanced  Research  Projects  Agency  (DARPA)  project.  The  DARPA  project 
has  resulted  in  the  capability  to  control  simulated  Future  Combat  System  (FCS) 
unmanned  ground  vehicles.  Faculty  will  modify  the  CECOM  interface  for  ground 
vehicles  to  enable  providing  the  data  needed  by  the  cadet  project.  However,  the  dynamics 
for  the  targets,  obstacles,  and  missiles  will  also  have  to  be  added.  The  plan  is  to  have 
faculty  modify  a  solution  available  from  the  Mathworks  that  implements  some  prior  work 
in  controlling  a  swarm  of  missiles  to  engage  a  set  of  targets  [10]. 

Partitioning  of  system  components 

The  cadet  project  will  compare  different  command  and  control  architectures  so  a  high- 
level  task  is  to  decide  upon  an  approach  for  architecture  comparison.  A  fundamental  issue 
in  comparing  command  and  control  architectures  is  the  relative  effectiveness  of  the 
architecture  in  supporting  development  and  execution  of  a  commander’s  concept  of  the 
operation.  For  the  cadet  project  we  will  not  explore  the  semantics  of  commander’s  intent 
in  the  framework  of  a  concept  of  the  operation  but  constrain  the  problem  at  hand  to  issues 
surrounding  implementing  alternatives  for  centralized,  semi-autonomous  and  autonomous 
engagement  of  targets  by  loitering  missiles.  Such  a  problem  requires  close  attention  to  the 
details  of  communicating  time-sensitive  information  among  architecture  components. 
Such  time-sensitive  information  includes:  updated  target  lists,  updated  target 
prioritizations,  changes  in  the  defense  condition,  and  changes  in  the  rules  of  engagement. 
The  cadet  project  Software  Requirements  Specification  (SRS)  states  that: 

There  are  three  architectures  that  must  be  examined  for  use  in  the  system: 

Centrally  controlled,  man-in-the-loop  semi-autonomous,  and  autonomous. 

The  centrally  controlled  architecture  has  a  ground-based  controller  giving 
commands  to  the  missiles  for  everything  they  do.  The  semi-autonomous 
architecture  allows  a  controller  to  input  commands  to  missiles,  however 
missiles  will  operate  on  their  own  without  additional  commands.  Fully 
autonomous  operation  occurs  when  the  ground-based  controller  selects  the 
autonomous  mode  or  the  missile  has  lost  communication  with  the  controller. 

The  pros  and  cons  of  each  architecture  must  be  determined  and  weighed  in 
the  implementation  of  the  system. 

An  architecture  comparison  approach  that  has  been  used  in  the  past  [7]  has  been  provided 
to  the  cadet  team.  Also,  iterative  architecture  development  through  a  spiral  process  of 
“build  a  little,  test  a  little”  requires  an  architecture  comparison  methodology  to  indicate 
directions  for  improvement.  The  remainder  of  this  section  discuses  an  initial 
methodology  proposed  by  researchers  at  the  Software  Engineering  Institute  and  suggests 
changes  which  make  the  approach  appropriate  for  comparing  time-sensitive  architectures. 

The  Software  Architecture  Analysis  Method  (SAAM)  [11]  has  been  proposed  as  a 
methodology  for  comparing  alternative  software  architectures.  The  steps  proposed  in 
SAAM  are: 

1 .  Characterize  a  canonical  functional  partitioning  for  the  domain. 

2.  Map  the  functional  partitioning  onto  the  architecture’s  structural  decomposition. 
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3.  Choose  a  set  of  quality  attributes  with  which  to  assess  the  architecture. 

4.  Choose  a  set  of  concrete  tasks  that  test  the  desired  quality  attributes. 

5.  Evaluate  the  degree  to  which  each  architecture  provides  support  for  each  task. 

However,  while  SAAM  provides  a  methodology  for  architecture  comparison,  it  must  be 
modified  for  use  in  evaluating  distributed,  real-time  architectures.  Specifically,  SAAM  is 
incomplete  for  comparing  alternative  distributed,  real-time  architectures.  The 
incompleteness  occurs  in  two  areas:  (1)  explicit  consideration  of  communication  between 
architectural  components  is  not  discussed  and  is  fundamental  to  distributed,  real-time 
architectures  since  communications  links  in  an  application  architecture  may  vary  over 
time  between  zero  bandwidth  and  essentially  infinite  bandwidth,  and  (2)  distributed,  real¬ 
time  processes  contain  many  feedback  loops  which  result  in:  (a)  a  need  to  analyze  a  set  of 
components  to  determine  the  next  state  of  the  set  of  components  (i.e.  it  is  not  correct  to 
analyze  a  component  in  isolation)  and  (b)  the  notion  of  letting  a  set  of  components  “settle 
out”  over  a  period  of  time  before  the  next  set  of  input  values  are  processed  (i.e.  the  idea 
of  a  time  constant  associated  with  a  process). 

Concerning  the  first  SAAM  incompleteness  issue,  communication  can  often  be  assumed 
to  not  be  an  issue,  especially  whenever  the  architecture  under  consideration  will  be 
implemented  such  that  communication  between  modules  is  almost  instantaneous.  Even 
in  this  case,  communication  between  modules  probably  should  be  accounted  for  at  the 
reference  architecture  level.  However,  for  architectures  involving  large  distributed 
systems,  analyzing  communications  processes  between  modules  is  necessary  and  will 
normally  involve  at  least  a  fixed  delay  (latency)  of  messages  at  the  simplest  level  and,  for 
complex  systems,  may  require  use  of  specialized  tools  to  record  or  simulate  actual 
message  preparation,  transmission,  propagation,  receiving,  and  processing  activities. 
Certainly  for  our  domain  of  interest,  distributed  real-time  systems,  communication  is  an 
integral  member  of  the  problem  space  and  must  be  explicitly  considered.  Establishing 
communication  between  modules  should  be  a  step  in  the  architecture  development 
process,  equal  with  partitioning  the  problem  space  and  assigning  functional  modules  to  a 
structure. 

Concerning  the  second  SAAM  incompleteness  issue,  the  canonical  functional  partitioning 
will  normally  result  in  components  whose  internal  state  depends  only  on  the  previous 
state  and  current  inputs.  The  component  independence  assumption  is  true  most  of  the 
time  for  those  components  supporting  higher-level  decisions  leading  to  engagement 
events,  especially  force  operations  decisions  which  set  the  environment  for  use  of  deadly 
force.  However,  the  component  independence  assumption  is  almost  never  true  for 
modeling  lower-level  physical  processes,  such  as  aircraft  and  missile  guidance  control, 
sensor  control,  and  control  of  engagement  processes,  all  of  which  are  integral  processes 
of  the  distributed,  real-time  problem  space.  Stated  another  way,  for  military  applications, 
the  failure  of  the  independence  assumption  for  distributed,  real-time  components  arises 
from  the  fact  that  the  distributed  nature  of  motion  in  the  battlespace  (e.g.  ships,  missiles, 
aircraft,  tanks,  helicopters,  troops,  ...)  means  that  very  high-level  decisions  can  result  in 
producing  constraints  which  dramatically  change  the  operational  environment  for  low- 
level  components.  The  low-level  components  then  quickly  produce  different  outputs 
which  change  the  state  of  the  higher-level  components  inside  their  decision  cycle  (i.e.  the 
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component  independence  assumption  is  invalid  because  we  have  a  mixed-signal,  or 
hybrid,  problem  space). 

Distributed,  Real-time  Architecture  Comparison  Requirements: 

While  functional  segmentation  is  a  natural  approach  to  follow  in  construction  of  software 
modules  (since  implemented  functionality  of  software  process  models  and  data  schema 
can  be  directly  related  to  user  functional  requirements),  the  functional  partitioning  of 
components  may  not  be  the  best  approach  for  architecture  development.  An  architectural 
comparison  approach  is  thus  required.  The  relative  ability  of  alternative  software, 
hardware  and  communications  architectures  to  react  to  expected  failure  modes  will  be 
determined  by  the  detailed  partitioning  of  required  operations  into  functional  modules, 
the  mapping  of  resulting  distributed  software  processes  onto  the  distributed  computation 
and  communication  resources,  and  the  execution  of  combined  system  functionality  across 
components  which  may  be  widely  distributed  in  space  and  time. 

A  Real  Time  Software  Architecture  Analysis  Method  (RT  -  SAAM): 

An  approach  for  comparing  alternative  distributed,  real-time  software  architectures  is: 

1 .  Build  a  set  of  software  architectures  for  the  distributed,  real-time  problem  space  by 
repeatedly: 

a.  1  Identify  a  level  above  which  system  behavior  is  to  be  determined  by  modifying 
logical  parameters  only  and  partition  the  problem  space  (tasks)  into  appropriate 
higher-level  functional  modules  using  event-based  models, 

a. 2.  Below  the  level  identified  in  step  al,  partition  the  problem  space  (tasks)  into 

functional  modules,  some  strictly  event-based  models,  some  a  mixture  of  event- 
based  models  and  differential-algebraic-equation-based  models. 

b.  Assign  modules  to  a  computational  structure  (usually  pipe  and  filter  computational 
style),  and 

c.  Establish  communication  between  modules. 

2.  Choose  a  set  of  quality  attributes  with  which  to  assess  the  architectures  (pick  success 
criteria), 

3.  Choose  a  set  of  concrete  tasks  which  test  the  desired  quality  attributes,  and 

4.  Evaluate  the  degree  to  which  each  architecture  provides  support  for  each  task. 

For  the  cadet  problem,  the  simulation  environment,  the  One  Semi-Automated  Forces 
(OneSAF)  Test  Bed  (OTB),  handles  the  details  of  the  physics-based  modeling.  Thus,  the 
cadet  team  implementation  must  explore  the  details  of  step  la,  2,  3,  and  4  of  RT-SAAM. 

Simulation  system  and  interface  between  components 

We  are  using  the  extensible  Markup  Language  (XML)  as  an  interface  definition 
language  for  the  interface  between  the  OneSAF  simulation  environment  and  the  student 
simulation  components.  An  example  of  messages  to  the  missiles  is  given  in  Figure  1. 

The  syntax  of  the  messages  is  given  in  the  data  type  definition  of  Figure  2 
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<?xml  version="1.0"  ?> 


<!DOCTYPE  messages  (View  Source  for  full  doctype...)> 
essages> 

< !—  Message  from  missile  network  to  simulation  environment. 

Missile  ml:  vioalte  physical  laws  and  reposition  as  indicated 
Missile  m2 :  set  a  new  temporary  waypoint  to  avoid  a  collision 


Missile  m3:  set  a  new  (permanent)  loiter  pattern  — > 

;ssage  command="PUT"  messageld="100"> 
ssile  command="godHand"  missileld="ml"> 
ocation  lat="22311"  lon=”56478"  alt="350"  /> 
velocity  north="112"  east="0"  down="0"  /> 

</missile> 

ssile  command="setWaypoint"  missileld  =  "m2"> 

vaypoint  waypointld  =  "0"  lat="12345"  lon  =  "12345"  alt="250"  /> 

</missile> 

ssile  command="setWaypoint"  missileld  =  "m3"> 
vaypoint  waypointId  =  "l"  lat="13345"  lon  =  "13345"  alt="250"  /> 
vaypoint  waypointId  =  "2"  lat="14345"  lon  =  "13345"  alt="250"  /> 
vaypoint  waypointId  =  "3"  lat="14345"  lon  =  "14345"  alt="250"  /> 
vaypoint  waypointId  =  "4"  lat="13345"  lon  =  "14345"  alt="250"  /> 
</missile> 

</message> 

< !—  Message  from  missile  network  to  simulation  environment. 

Missile  m3:  launch  — > 

;ssage  command="PUT"  messageld="101"> 
nissile  command="launch"  missileld="m3"  /> 

</message> 

< !—  Message  from  missile  network  to  simulation  environment. 

Get  all  update  messages  for  all  missiles.  --> 

nessage  command="GET"  messageld="101"  /> 

< !—  Message  from  missile  network  to  simulation  environment. 

Get  all  update  messages  for  missile  m2.  — > 

;ssage  command="GET"  messageld="102"> 
nissile  missileld="m2"  /> 

</message> 

< !—  Message  from  missile  network  to  simulation  environment. 

Abort  (detonate)  missile  m2.  — > 

;ssage  command="PUT"  messageld="103"> 
nissile  command="abort"  missileld="m2"  /> 

</message> 

< !—  Message  from  simulation  environment  to  missile  network. 

Update  message  for  missile  m3.  — > 

lessage  messageld="644"  command="get"> 
lissile  missileld="abc"> 

ocation  lat="13345"  lon="13345"  alt="250"  /> 

'elocity  north="112"  east="0"  down="0"  /> 

</missile> 

</message> 

</messages> 


Figurel.  Example  messages  to  missiles 
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<?xml  version="1.0"  ?> 

<!  ELEMENT  messages  (message+)> 

<!ELEMENT  message  (missile*)> 

<!  ATTLIST  message  command  (put|get)  "get"  > 

<!  ATTLIST  message  messageld  CD  AT  A  #REQUIRED  > 

<!  ATTLIST  message  timestamp  CDATA  #IMPLIED> 
<!ELEMENT  missile  (location?,  velocity?,  waypoint*)> 

<!  ATTLIST  missile  command  (abort|godHand|launch|setWaypoint) 
#IMPLIED> 

<!  ATTLIST  missile  missileld  CDATA  #REQUIRED  > 

<!  ATTLIST  missile  timestamp  CDATA  #REQUIRED> 

<!  ELEMENT  location  EMPTY> 

<!  ATTLIST  location  lat  CDATA  #REQUIRED> 

<!  ATTLIST  location  Ion  CDATA  #REQUIRED> 

<!  ATTLIST  location  alt  CDATA  #REQUIRED> 

<!  ELEMENT  velocity  EMPTY> 

<!  ATTLIST  velocity  north  CDATA  #REQUIRED> 

<!  ATTLIST  velocity  east  CDATA  #REQUIRED> 

<!  ATTLIST  velocity  down  CDATA  #REQUIRED> 

<!  ELEMENT  waypoint  EMPTY> 

<!  ATTLIST  waypoint  waypointld  CDATA  #REQUIRED> 

<!  ATTLIST  waypoint  lat  CDATA  #REQUIRED> 

<!  ATTLIST  waypoint  Ion  CDATA  #REQUIRED> 

<!  ATTLIST  waypoint  alt  CDATA  #REQUIRED> 


Figure  2.  Document  Type  Definition  for  the  missile  interface 


Summary 

As  discussed  above,  we  are  building  a  simulation  environment  to  experiment  with  the 
comparison  of  command  and  control  architectures.  In  particular,  a  cadet  team  is 
investigating  the  relative  efficacy  of  autonomous,  semi-autonomous,  and  centralized 
control  of  a  next-generation  autonomous  combat  vehicle.  However,  we  expect  that  the 
simulation  framework  we  are  creating  will  also  be  useful  for  experimenting  with  a  wide 
range  of  issues  surrounding  the  interface  of  autonomous  and  man-in-the-loop  decision 
support  systems. 

In  addition,  we  expect  the  simulation  environment  to  support  faculty  research  into  other 
areas  of  interest.  Concerning  possible  faculty/other  research  issues,  it  should  be  noted  that 
the  OneSAF  software  is  expected  to  provide  event-based  simulations  of  operational 
scenarios  and  the  Matlab/Simulink  software  is  expected  to  provide  continuous  time  and 
space  simulations  as  well  as  the  link  between  event-based  and  continuous  simulations.  A 
rich  environment  of  the  system  state  will  thus  be  available.  In  this  environment,  the  only 
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invariant  is  expected  to  be  the  commander's  intent  with  all  other  system  parameters  being 
subject  to  change  during  the  duration  of  the  simulation.  The  set  of  issues  associated  with 
NLOS-LS  networked  communications  (such  as  QoS,  bandwidth  allocation, 
trustworthiness  of  system  state  parameters,  ...)  is  an  area  of  research  that  is  essentially 
open-ended.  Another  area  that  has  been  investigated  for  many  years  without  resolution  is 
the  fusion  of  network  sensor  data  (such  as  target  identification,  target  update,  obstacle 
identification,  obstacle  update, ...). 
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An  Environment  for 
Comparing  Command  and 
Control  Architectures 


“Know  the  enemy,  know  yourself;  your  victory  will 
never  be  endangered.  Know  the  ground,  know  the 
weather;  your  victory  will  then  be  total”* 

We  need  improved  information  assurance  standards  to 
enable  joint  interoperability”** 

Dr.  John  James,  Maj  Fernando  Maymi 
John. James,  Femando.Maymi@usma.edu 


*  The  Art  of  War  by  Sun  Tzu  ,  Translated  by  Samuel  B.  Griffith,  Page  129 
**  GEN  Paul  Kern,  CG,  AMC,  plenary  speaker,  IEEE  Information  Assurance  Workshop,  West  Point,  NY,  18  June  2003 
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Contents 


•  Hybrid  systems  (mixed-signal  systems) 

-  Command  and  Control  (high-level  control) 

-  Target  Engagement  (low-level  control) 

-  Information  Assurance  (an  enterprise  service) 

•  An  Environment  for  Comparing  Command  and  Control 
Architectures 


-  The  OneSAF  Objective  System  (goal:  mission  rehearsal) 

-  The  Future  Combat  System  (manned  and  autonomous  systems) 

-  The  Foitering  Attack  Missile  (autonomous  indirect  fire) 

•  Alternative  Architectures 


-  Centralized  control 

-  Semi-autonomous  control  (man-in-the-loop) 

-  Autonomous  control  (missiles  select  and  engages  targets) 
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Command  and  Control  is  a  Hybrid  System 
e.g.  Maintaining  Running  Estimates 


Figure  5-1  of  FM  2-0  Intelligence  “Common  Operational  Picture  and  Running  Estimates” 
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Command  and  Control  is  a  Hybrid  System 
e.g.  Autonomous  Missile  Control 


Common  Jam  Resistant  Digital  Targeting 

•GPS  for  accurate  search  and  target  location. 
•Data  link  provides  targeting  coordinates  and 
BDA  to  operator  and  allows  in-flight  missile 
retasking 

Flexible  Lethality 

Multimode  warhead  for  light  armor  and  soft 
targets 

Common  Vertical  Launch  Compatibility 

Booster  rocket  and  mini-turbo  jet  sustainer 
motor  allows  launch  from  same  C/LU  as  PAM 

High  Capability  Seeker 


LADAR  seeker  uses  ATR 
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Target  Engagements  are  Hybrid  Systems 
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Ballistic  Missile  Engagements  fjg 
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Information  Assurance  services  whose 
values  (states)  change  over  time 


Enterprise  Services  are  Hybrid  Systems 
e.g.  Maintenance  of  trust  in  distributed  component 


Accreditation  processes  occur  over  time 


INFORMATION 

STATES 

SERVICES 

TRANSMISSION 

STORAGE 

PROCESSING 

SECURITY 

SERVICES 
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INTEGRITY 

AVAILABILITY 

AUTHENTICATION 

NONREPUDIATION 

SECURITY 

MAINTENANCE 

SERVICES 

PROTECTION 

DETECTION 

REACTION 

SECURITY 

COUNTER 

MEASURES 

SERVICES 

TECHNOLOGY 

POLICIES  AND  PRACTICES 

PEOPLE 

INFORMATION 

DOMINANCE 

SERVICES 

SITU  ATTON  A  S  SE  S  SMEN  T  SUPPORT 

MILITARY-DE CISIONMAKINGP ROCE SS  SUPPORT 

TRUTH-MAINTENANCE  SUPPORT 

Components  are  distributed  in 
time  and  space 
Trust  is  necessarily  a  locally 
maintained  estimate 
Friendly  and  enemy  activities 
result  in  continual  system  changes 
The  only  system  invariant  is 
usually  the  commander’s  intent 
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An  Environment  for  Comparing 
Command  and  Control  Architectures 

•  The  OneSAF  Objective  System  (OOS) 

-  Will  support  creation  of  mission  scenarios  for  various  Battlefield 
Operating  Systems  (BOS) 

-  A  goal  of  OneSAF  is  to  enable  mission  rehearsal  enroute  to  an 
operation 

•  The  Future  Combat  System 

-  Will  have  enhanced  connectivity  to  a  variety  of  information  systems 

-  Will  interface  with  both  manned  and  autonomous  systems 

•  The  Loitering  Attack  Missile 

-  Is  the  long-duration  component  of  the  Non-Line-of-Sight  Launch 
System  (NLOS-LS) 

-  Will  have  an  autonomous  mode  of  delivering  indirect  fires 

•  We  will  use  an  extensible  Markup  Language  (XML)-based 
messaging  interface  to  link  the  different  models 
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Software  Architecture  Analysis 

Method 


•  Characterize  a  canonical  functional  partitioning  of  the 
domain 

•  Map  the  functional  partitioning  onto  the  architecture’s 
structural  decomposition 

•  Choose  a  set  of  quality  attributes  with  which  to  assess  the 
architecture 

•  Choose  a  set  of  concrete  tasks  that  test  the  desired  quality 
attributes 

•  Evaluate  the  degree  to  which  each  architecture  provides 
support  for  each  task 
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Modifying  SAAM  for  Real-Time, 
Distributed  Architectures 


•  Need  explicit  consideration  of  communication 
links  between  distributed  components 

•  Need  explicit  consideration  of  characteristics  of 
feedback  loops: 

-  Need  to  analyze  a  set  of  components  to 
determine  next  state  of  the  set  of  components 

-  Need  to  let  the  system  “settle-out”  before  the 
next  perturbation 
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Architecture  Analysis  Methodology 

•  Build  a  functionally-oriented  set  of  architectures  by: 

-  Partitioning  higher  level  problem  space  into  task-oriented  modules  using  event- 
based  models 

-  Partitioning  lower-level  problem  space  into  mixtures  of  event-based  modules  and 
Differential  Algebraic  Equation  (DAE)  based  models 

-  Assigning  modules  to  a  computational  structure  (usually  a  “pipe-and-filter” 
structure) 

-  Establishing  communication  between  modules 

•  Choose  a  set  of  quality  attributes  with  which  to  assess  the 
architectures  (pick  success  criteria) 

•  Choose  a  set  of  concrete  tasks  which  test  the  desired  quality 
attributes,  and 

•  Evaluate  the  degree  to  which  each  architecture  provides  support 
for  each  task 
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A  Missile  Messaging  Structure 

<?xml  version="1.0"  ?> 

<!DOCTYPE  messages  (View  Source  for  full  doctype...)> 

<messages> 

< !—  Message  from  missile  network  to  simulation  environment. 

Missile  ml:  violate  physical  laws  and  reposition  as 
indicated 

Missile  m2 :  set  a  new  temporary  waypoint  to  avoid  a 
collision 

Missile  m3:  set  a  new  (permanent)  loiter  pattern 

> 

cmessage  command="PUT"  messageld="100"> 

cmissile  command="godHand"  missileld="ml"> 

< location  lat="22311"  lon  =  "56478"  alt="350"  /> 

<velocity  north="112"  east="0"  down="0"  /> 

</missile> 

<missile  command="setWaypoint"  missileld="m2"> 

<waypoint  waypointId  =  "0"  lat="12345"  lon  =  "12345"  alt="250"  /> 
</missile> 

<missile  command  =  "setWaypoint"  missileld="m3"> 

<waypoint  waypointId  =  "l"  lat="13345"  lon  =  "13345"  alt="250"  /> 
<waypoint  waypointId  =  "2"  lat="14345"  lon  =  "13345"  alt="250"  /> 
<waypoint  waypointId  =  "3"  lat="14345"  lon  =  "14345"  alt="250"  /> 
<waypoint  waypointId  =  "4"  lat="13345"  lon  =  "14345"  alt="250"  /> 
</missile> 

</message> 

<!—  Message  from  missile  network  to  simulation 
environment . 

Missile  m3:  launch  — > 

cmessage  command="PUT"  messageld  =  "101"> 
cmissile  command="launch"  missileld="m3"  /> 
c/message> 
c/messages> 
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A  Missile  Messaging  Structure 


<?xml  version="1.0"  ?> 

<!DOCTYPE  messages  (View  Source  for  full  doctype...)> 

<messages> 

< !—  Message  from  missile  network  to  simulation  environment. 

Missile  ml:  violate  physical  laws  and  reposition  as  indicated 
Missile  m2 :  set  a  new  temporary  waypoint  to  avoid  a  collision 
Missile  m3:  set  a  new  (permanent)  loiter  pattern  — > 

<!-- Message  from  missile  network  to  simulation  environment. 


<! —  Message  from  missile  network  to  simulation  environment. 

Get  all  update  messages  for  all  missiles.  — > 

<message  command=MGETM  mes sage Id=" 101 "  /> 

<! —  Message  from  missile  network  to  simulation  environment. 

Get  all  update  messages  for  missile  m2 .  — > 

<message  command="GET"  messageld="102"> 

<missile  missileld="m2 "  /> 

</message> 

< ! —  Message  from  missile  network  to  simulation  environment. 

Abort  (detonate)  missile  m2.  — > 

<message  command="PUT"  messageld="103"> 

<missile  command= M abort "  missileld="m2 M  /> 

</message> 

< ! —  Message  from  simulation  environment  to  missile  network. 

Update  message  for  missile  m3.  — > 

— <message  messageld=" 644 "  command="get "> 

-<missile  missileld="abcn> 

location  lat="13345"  lon  =  M13345M  alt=M250M  /> 
cvelocity  north  =  M112M  east=M0"  down  =  M0M  /> 

</missile> 

</message> 

</messages> 
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Modeling  Swarms  of  Autonomous  Missiles 


E3  Multiple  UAV  Simulation:  uavl_side  (-328.63  -3633.87  9619.89) 


-Inl  x| 


Matlab-Simulink  model  of  a  formation  of  Multiple  UAVs 
avoiding  multiple  obstacles  to  engage  targets* 
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Autonomous  LAMs 


L 

L 

L 

-► 

L 

8  km 

25  km 


-  Enemy  Target  (s) 


A 


-  Friendly  Asset 


-  LAM  Launcher  /  Controller 


Symbol  Key 
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Autonomous  TOCs 


Enemy  Target  (s) 


Friendly  Point  Asset 


-  LAM  Launcher  /  Controller 


j  -  Tactical  Operations  Center  (TOC) 


Symbol  Key 
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Two-Tier  Centralized 


Symbol  Key 


http://www.itoc.usma.edu 


17 


One-Tier  Centralized 


-  Enemy  Target  (s) 

-  Friendly  Point  Asset 

-  LAM  Launcher  /  Controller 


-  Tactical  Operations  Center  (TOC) 


Symbol  Key 
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Peer-to-Peer  Netted 


-  Enemy  Target(s) 

-  Friendly  Point  Asset 

-  LAM  Launcher  /  Controller 


-  Tactical  Operations  Center  (TOC) 


Symbol  Key 
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Messaging  Interface  to  OneSAF 

•  The  initial  version  of  the  Mercury  messaging  interface  to  the 
OneSAF  Objective  System  (OOS)  has  been  completed 

-  Interface  to  cadet  code  for  airspace  de-confliction  is  operational 

-  Will  be  interfaced  to  the  OOS  this  Summer 

•  The  Matlab  Simulink  code  generates  a  Virtual  Reality 
Modeling  Language  (VRML)  simulation  of  three  behaviors: 

-  Formation  keeping, 

-  Target  seeking,  and 

-  Collision  Avoidance 

•  The  expectation  is  that  a  cadet  team  next  year  will  build  on 
the  results  of  this  year  to: 

-  Evaluate  alternative  command  and  control  architectures,  and 

-  Investigate  information  assurance  aspects  of  the  distributed  control 
problem 
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Summary 


•  Critical  infrastructure  processes  (such  as  military 
operations)  are  hybrid  systems  (i.e.  have  discrete  and 
continuous  components) 

•  Understanding  (controlling)  complex  dynamical  processes 
requires  explicit  modeling  of  both  discrete  and  continuous 
components 

•  Integration  of  service  and  coalition  command  and  control 
systems  will  necessarily  require  on-line,  adaptive 
certification  of  the  level  of  trust  of  new  system  components 

•  Future  command  and  control  systems  will  feature 
centralized,  semi-autonomous  and  autonomous  control  of 
various  joint  force  components  in  order  to  meet  enterprise 
process  goals  (commander’s  intent(s)) 
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